[アップデート] Amazon EBSの複数インスタンスへのアタッチが可能になりました!(プロビジョンドIOPS io1ボリュームに限る)

[アップデート] Amazon EBSの複数インスタンスへのアタッチが可能になりました!(プロビジョンドIOPS io1ボリュームに限る)

使い所には注意が必要ですが、EBSを複数のEC2インスタンスにアタッチする構成に対応しました。
Clock Icon2020.02.15

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

コンバンハ、千葉(幸)です。

いくつか制約付きで、EBSボリュームを複数のEC2インスタンスにアタッチ(マルチアタッチ)できるようになりました!

https://aws.amazon.com/jp/about-aws/whats-new/2020/02/ebs-multi-attach-available-provisioned-iops-ssd-volumes/

制限・考慮事項

  • I/Oフェンシングプロトコルに対応していないため、アプリケーション側で同時書き込みの排他制御を担保する必要がある
  • ボリュームタイプは プロビジョンドIOPS(io1) である必要がある
  • マルチアタッチするEC2インスタンスはEBSボリュームと同一アベイラビリティゾーンである必要がある
  • マルチアタッチするEC2インスタンスはNitroベースのインスタンスである必要がある
  • マルチアタッチできるのは最大16台まで
  • 現状マルチアタッチできるのはus-east-1、us-east-2、us-west-2、eu-west-1、ap-northeast-2である
    • 執筆時点で東京リージョンはまだ!
  • マルチアタッチ対応ボリュームはブートボリュームとして作成できない
  • マルチアタッチ対応ボリュームはインスタンスごとにアタッチできるのは1つのデバイスのみ
  • ボリュームの作成後にマルチアタッチの有効/無効を変更することはできない
  • マルチアタッチ対応ボリュームのボリュームタイプ、サイズ、プロビジョンドIOPSを変更することはできない
  • EBSの物理ホストに影響があった場合、マルチアタッチしているEC2インスタンスすべてで使用できない
  • EC2インスタンスにおけるEBSボリュームの「終了時に削除」の有効/無効は、最後にアタッチされたEC2インスタンスの設定が採用される

詳細は以下をご確認ください。

https://docs.aws.amazon.com/ja_jp/ebs/latest/userguide/ebs-volumes-multi.html

やってみた

以下のブログを参考に、やっていきます。

https://aws.amazon.com/jp/blogs/aws/new-multi-attach-for-provisioned-iops-io1-amazon-ebs-volumes/

EBSの作成

今回はus-east-1で試してみます。ボリュームタイプでプロビジョンドIOPSを選択すれば、マルチアタッチの有効/無効を選択できるようになっています。

EC2へのアタッチ

今回はすでに同一AZに2台のEC2インスタンスを作成済みです。

  • amzn2-ami-hvm-2.0.20200207.1-x86_64-gp2(ami-0a887e401f7654935)
  • t3.micro

EBSボリュームの画面から、それぞれのインスタンスにアタッチしていきます。デバイスはデフォルトの/dev/sdfにしています。

2台目も同様に。

EBSの画面から、それぞれにアタッチされたことが確認できます。

EC2インスタンスの側からはこのように確認できます。「終了時に削除」は、デフォルトでfalseになっています。変更する場合は、マネジメントコンソールからでは不可のため、CLIやSDKで実施する必要があります。

OSでの確認

今回はSSMで接続してみます。まずは1号機での作業です。

デバイス/dev/sdfとしてアタッチしたEBSを、ファイルシステムタイプxfsでフォーマットし、/dataにマウントしています。

/data配下にfile.txtを作成し、このファイルを2号機からも参照できることをゴールとします。

sh-4.2$ uname -a
Linux ip-192-168-1-239.ec2.internal 4.14.165-131.185.amzn2.x86_64 #1 SMP Wed Jan 15 14:19:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
sh-4.2$ whoami
ssm-user
sh-4.2$ sudo mkfs -t xfs /dev/sdf
meta-data=/dev/sdf               isize=512    agcount=4, agsize=655360 blks
         =                       sectsz=512   attr=2, projid32bit=1
         =                       crc=1        finobt=1, sparse=0
data     =                       bsize=4096   blocks=2621440, imaxpct=25
         =                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =internal log           bsize=4096   blocks=2560, version=2
         =                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =none                   extsz=4096   blocks=0, rtextents=0
sh-4.2$ sudo mkdir /data
sh-4.2$ sudo mount /dev/sdf /data
sh-4.2$ cd /data
sh-4.2$ sudo vi file.txt
sh-4.2$ cat file.txt
Hello from a Multi-Attach EBS volume!;)
sh-4.2$

(コマンドの意味が自分の中で怪しかったのでメモ。)

  • mkfs -t <ファイルシステムの種類> <デバイス名>
  • mount <デバイス> <マウントポイント>

2号機側での作業です。
同じように/dev/sdf/dataにマウントし、file.txtを確認します。

sh-4.2$ uname -a
Linux ip-192-168-1-178.ec2.internal 4.14.165-131.185.amzn2.x86_64 #1 SMP Wed Jan 15 14:19:56 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
sh-4.2$ whoami
ssm-user
sh-4.2$ sudo mkdir /data
sh-4.2$ sudo mount /dev/sdf /data
sh-4.2$ cd /data
sh-4.2$ cat file.txt
Hello from a Multi-Attach EBS volume!;)

問題なくfile.txtの中身のHello from a Multi-Attach EBS volume!;)が確認できました。

ちなみに

上記の状態で、1号機と2号機で同じファイルに対して読み書きができる状態になっていると勘違いしていたのですが、そのようなことはありませんでした。1号機、2号機それぞれで加えた変更は、相手側からは見えておらず、アンマウント→マウントし直すといずれか一方の最終状態が見える、という挙動でした。ファイルシステムのタイプや、マウントの仕方によって変わる部分かと思います。

▼追記 ここから

関連する記述が公式からアナウンスされていました。

EBS Multi-Attach では、標準ファイルシステムはサポートされていません。XFS、EXT3、EXT4、NTFS などのファイルシステムは、複数のサーバーまたは EC2 インスタンスが同時にアクセスするようには設計されていません。したがって、これらのファイルシステムには、書き込み、読み取り、ロック、キャッシュ、マウント、フェンシングなどの調整と制御を管理するための組み込みメカニズムがありません。
複数のサーバーが標準ファイルシステムに同時にアクセスできるようにすると、データの破損または損失が発生する可能性があります。EBS Multi-Attach ボリューム上の標準ファイルシステムを操作できるようにする設定は、サポートされていません。
今回の例ではxfsを用いてインスタンスを跨いだ参照を行っていますが、あくまで分かりやすさを重視するためのものであり、実際の運用で使用できる状態ではありません。本番設計においてはさらに多くを考慮する必要があるでしょう。

▲追記 ここまで

おまけ

fdisk -lコマンドでデバイス/dev/sdfが確認できると思ったのですが、/dev/nvme1n1という見慣れない文字が。

sh-4.2$ sudo fdisk -l
Disk /dev/nvme0n1: 8 GiB, 8589934592 bytes, 16777216 sectors #EC2ローンチ時に作成したEBS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 65E66B8B-7479-4A5D-8D3C-3570E8F219E7

Device           Start      End  Sectors Size Type
/dev/nvme0n1p1    4096 16777182 16773087   8G Linux filesystem
/dev/nvme0n1p128  2048     4095     2048   1M BIOS boot

Partition table entries are not in disk order.

Disk /dev/nvme1n1: 10 GiB, 10737418240 bytes, 20971520 sectors #マルチアタッチしたEBS
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes

Nitroベースのインスタンスの場合はそのように表示されるようです。

Nitro ベースのインスタンスでは、EBS ボリュームは NVMe ブロックデバイスとして公開されます。デバイス名は、/dev/nvme0n1、/dev/nvme1n1 などです。ブロックデバイスマッピングで指定したデバイス名は、NVMe デバイス名 (/dev/nvme[0-26]n1) を使用して名称変更されます。

以下のコマンドで元のデバイス名を確認することができます。

sh-4.2$ sudo /sbin/ebsnvme-id /dev/nvme1n1
Volume ID: vol-04c169afe360df05d
/dev/sdf

終わりに

「EBSは複数のインスタンスで共有できない」というのは長らく常識であったので、個人的には少し驚きのアップデートでした。クラスタ製品など、EBSの共有ができないためにAWSでの実装ができなかったものが、このアップデートによって解消されるかもしれません。

ただ、「オンプレではこういうことができていたから、AWSでも同じ構成にしたい!」の一助になるアップデートではありますが、果たしてそれが正解なのか?というのはよくよく考慮が必要かと思います。どういった使い道があるのかは、これからよく揉まれていくことでしょう。ウォッチしていきます。

▼追記

弊社しばたが使い所を考察したエントリを書きましたので、ぜひご参照ください。

https://dev.classmethod.jp/articles/ebs-multi-attach-usecase-thought/

以上、東京の千葉でした!

参考サイト

Share this article

facebook logohatena logotwitter logo

© Classmethod, Inc. All rights reserved.